Dette technique : les solutions à mettre en place tout au long du développement

De la même façon qu’un immeuble construit il y a des dizaines d’années aura besoin alternativement de changements de fenêtres, à la structure ou encore d’un coup de peinture, il est important pour une solution numérique d’être proactivement maintenue pour éviter qu’elle ne se détériore avec le temps.

Lorsque cette proactivité n’est pas au rendez-vous, une dette technique (ou technologique) se crée. Ce terme est analogue au même terme dans le domaine des finances : tant qu’une dette technique n’est pas payée (corrigée), elle accumule des intérêts. Ceux-ci peuvent prendre plusieurs formes : érosion de l’architecture logicielle, réusinage (refactoring), bogues… Ils peuvent même causer des risques importants en sécurité ou causer de dettes techniques additionnelles.

Parce qu’il est fondamental d’être proactif dans la maintenance et dans l’évolution des solutions numériques, nous disposons d’une équipe complète constituée d’experts polyvalents qui garantissent le maintien des solutions numériques : l’équipe Évolution. Aujourd’hui, les membres de cette équipe nous font part de leurs connaissances et de leurs recommandations afin de limiter et de contrôler les risques liés aux dettes techniques.

Selon cet article (en anglais), la maintenance d’une solution numérique représenterait de 50 à 75 % des coûts totaux d’une solution. Selon notre expérience, les projets et les années, les coûts réels de maintenance, c’est-à-dire de mises à jour des systèmes, représenteront en moyenne selon les projets et selon les années un coût total de 10 à 20 % de l’investissement initial dans le projet. Les coûts d’évolution, eux, seront différents en fonction des objectifs d’affaires pour chaque solution numérique.

Il existe trois types de maintenance :

• Maintenance corrective, pour corriger les bogues informatiques;
• Maintenance évolutive, pour ajouter de nouvelles fonctionnalités au logiciel ;
• Maintenance performative, pour améliorer la maintenabilité du logiciel.

Le règlement de la dette technique se situe davantage au niveau de la maintenance performative, gage de pérennité d’une solution numérique.

Il existe plusieurs types de dettes techniques qui peuvent être repérées et priorisées à l’aide de la méthode SQALE (Software Quality Assessment based on Lifecycle Expectations, soit Évaluation de la qualité logicielle selon les attentes concernant le cycle de vie). Cette méthode repose sur neuf critères : réutilisabilité, portabilité, sécurité, utilisabilité, efficacité, altérabilité, fiabilité et testabilité.

Voici une liste des dettes techniques les plus courantes :

• Grande boule de boue (Big Ball of Mud) : système ou un logiciel n’ayant pas d’architecture évidente. Il peut être conseillé de réécrire complètement ce type de logiciel.
• Érosion de l’architecture logicielle : écart entre l’architecture prévue d’un logiciel et son implémentation. L’architecture d’un système logiciel ne permet plus de modifications puisque des changements continus introduits dans le système l’ont rendu impossible à maintenir. Dans ce cas particulier, on dira alors que le système est cristallisé.
• Programmation spaghetti : code non structuré et difficile à maintenir, pouvant être causé par plusieurs facteurs tels que des exigences changeantes dans un projet, l’absence de règles de style de programmation ou une ingénierie logicielle excessive.
• Code smell : bien que le terme soit subjectif, il s’agit d’une mauvaise pratique de conception ou d’implémentation logicielle qui conduit à l’apparition de défauts. Un code smell peut ralentir le développement d’une application ou d’une fonctionnalité, mais aussi causer de futurs bogues.
• Anti-patron (Antipattern) : erreurs de conception logicielle héritées de la phase de conception du logiciel, par l’absence ou la mauvaise utilisation de modèles de conception (design pattern). Ces erreurs ont souvent pour résultat une lenteur excessive du logiciel, des coûts de réalisation ou de maintenance élevés, des comportements anormaux et des bogues.

« Une dette technique n’est pas forcément mauvaise. Un développeur expérimenté peut introduire une dette technique consciemment afin de débloquer un projet ou de se conformer à un échéancier contraignant. Dans ce cas, la dette technique devrait être nommée, documentée et payée (ou corrigée) dès que possible », précise Julien Bonnier, développeur de l’équipe Maintenance & Support.

Ainsi « les dettes techniques peuvent être intégrées directement dans le carnet de produit (backlog) au même titre que des fonctionnalités à prioriser », explique Mathieu Fillion, Gestionnaire de l’équipe de développement.

Face à une situation de dette technique, l’objectif est de la rembourser rapidement pour éviter l’accumulation « d’intérêts ». Bien que la dette technique soit inévitable dans le développement logiciel, elle peut cependant être contrôlée en prenant différentes mesures tout au long du cycle de vie de l’outil numérique.

Dès l’étape de choix techniques en début de projet, il est important d’avoir à l’esprit les notions de pérennité des solutions choisies. En effet, la dette technique peut parfois être causée par le choix d’une solution plus facile à développer – au détriment d’une solution plus adaptée, mais qui exige plus de travail. Il faut donc avoir une vision à long terme pour effectuer un choix qui combine du mieux possible les impératifs de mise en marché et de durabilité.

Puisque les dettes techniques peuvent fréquemment être causées par des erreurs d’architecture ou de développement, les architectes et développeurs se doivent d’adopter différentes pratiques exemplaires pour limiter les risques de dettes techniques.

De nombreux processus sont implantés dans le sprint afin de contrer ces éventuelles erreurs, notamment la revue de l’architecture en début de projet, ou la revue des codes pour chaque requête tirée (pull request) lors du développement. D’autres pratiques très importantes s’intègrent également dans les processus dans une optique de DevSecOps : garder les bibliothèques à jour ou encore avoir et conserver des pipelines de déploiement continu pour permettre des corrections rapides lorsqu’une faille est décelée.

« Effectuer les mises à jour régulièrement augmente la prévisibilité de celles-ci et coûte beaucoup moins cher qu’une monstrueuse mise à jour risquée de temps en temps », nous explique Charles Lévesque, développeur de l’équipe de Maintenance & Support.

En effet, c’est le moyen idéal de mitiger le risque d’imprévus et donc le risque de dépassement de budget.

Pour conclure, la plus grande dette technique est toujours celle qui n’existe pas – soit l’absence de solutions numériques. Bien que les coûts de développement et de maintenance soient présents, en 2022, les bénéfices à adopter des outils numériques sont bien supérieurs à un système inexistant. La transformation numérique doit désormais faire partie des piliers de chaque organisation désirant assurer sa pérennité.